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(57) Abstract 

In known telephone 
systems it is very difficult to 
change call detailed records 
CDR formatted from a raw 
data flow. In the proposed 
method, the exchange 
supplier formats a special 
mother form, which is a file 
and which shows in plain 
language (in ASCII form) 
all names and parameters 
of fields in the raw data 
flow. The operator has a 
program using a graphic 
interface and showing the 
mother form in the display. 
Beside it a user form blank 
is seen and the user selects 
the fields he desires simply 
by dragging with the mouse 
the field of his choice from 
the mother form Into the 
user form and by dropping 
the field here (drag and 
drop). In this manner the 
user formats his own form, 
which contains such data 
only which he wishes to 

have in the CDR. When the user form has arrived at the telephone exchange and at the billing centre, it can be activated at any time. The 
formatting process hereby extracts from the raw data flow the data corresponding to fields stated in the form, thus formatting the CDR and 
sends it to the billing centre, which using the same form made by the user will Interpret the data contained in the received CDR, that is, it 
creates fields and attaches data belonging to fields from the CDR. Thus, the names of fields are not transferred from the exchange to the 
billing centre. 
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Extraction of desired data from data flow 
Field of the invention 

This invention concerns extraction of desired data from a structured 
5 data flow, especially extraction of predetermined data from a continuous flow 
of call detailed records produced by a telephone exchange. 

Background of the invention 

Billing in consequence of services is implementation of the agree- 

10 ment between the service producer and his customer. In principle, there are 
two kinds of billing: decentralised and centralised billing. 

In decentralised billing, the customer pays to the seller for each 
time of using services provided by the seller. The payment is performed ei- 
ther with conventional money or with some equivalent means of payment, 

15 e.g. postage stamps are used when paying for delivery of letters. A more re- 
cent example of a means of payment used in decentralised billing is elec- 
tronic money where each "coin" consists of a an encrypted binary sequence, 
which must be verified by a bank server. 

In centralised billing, the use of services is monitored by the seller 

20 or by a third party. The customer is billed periodically, e.g. once a month. 
The bill is based on monitoring data collected for the preceding billing period. 
Examples of centralised billing are electricity, telephone and credit card bill- 
ing. Centralised billing consists of three steps. The first step is an agreement 
between the parties on services and on related billing. The second step is 

25 monitoring (or measurement) of the use of services and saving of data con- 
cerning the use. The third step is formatting of the bill and sending the same 
to the customer. The bill is formed according to data saved in the billing 
system. 

The centralised billing used in a telephone network is based on an 
30 agreement between subscribers and operator. The essential point of the 
agreement is that the subscriber gets access to telephone sen/ices, that is. 
he may make and receive calls, and as a compensation for the service pro- 
vided he performs payments according to predetermined tariffs, as specified 
in bills sent to him by the operator. The bills typically include charging of two 
35 types: fixed charges and use charges. The fixed charges are independent of 
whether services are used or not. Use charges depend on how many calls 
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the subscriber has made and possibly also on how nnany calls he has re- 
ceived. To be able to debit for use charges the operator must monitor made 
and received calls. Such monitoring is connection-based and it Is performed 
by network switches. 

Figure 1 illustrates a known centralised billing method used in a 
telephone network by presenting a part of a public telephone network. For 
each call which is made the local exchange LE (the subscriber's Local Ex- 
change) performs a call detailed data collection and formats a CDR (Call 
Detailed Record). The record contains all the information required in billing 
for one call as well as any desired quantity of other information related to the 
call. Call detailed data collection is always used when specified detailed in- 
formation on a call is required for billing or for monitoring of call details. The 
structure of the call detailed record is determined by a an operation control 
command before the call detailed data collection is introduced. The record 
structure must be determined as a uniform structure in all exchange ele- 
ments controlled by the network management. Hereinafter the call detailed 
records will also be called by the name of CDR and the program formatting 
the call detailed records will be called the CDR generator. Formatted CDRs 
are sent to the BS (Billing Centre) for post processing. 

Formatting of the call detailed record requires that the operator es- 
tablish some basis for formatting of the call detailed record. Formatting may 
be based e.g. on call detailed data collection of all the calls of the subscriber 
or formatting may be based on the call type, that is, whether the call in ques- 
tion is a normal call, a facility call, such as call transfer etc., a call free of 
charge, , an IN call (intelligent network call) etc. In fixed network applications 
there are about 30 different formatting bases. The formatted call detailed re- 
cords are first saved in the memory and are then sent to the centralised bill- 
ing system, where they are saved in mass storage, e.g. on magnetic tape or 
on a hard disk. 

Between the exchange and the billing system there may also be an 
additional processing step, wherein call detailed data collection records are 
"pre-processed" for the billing system. Such pre-processing may be format- 
ting, where e.g. a tariff class field is converted from one format into another. 
Whether there is pre-processing or not, call detailed data collection will pro- 
duce enormous data blocks containing even millions of records, and these 
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may be saved in the billing system's mass storage. The records form the raw 
information which the billing system begins to process. 

Thus, processing of call detailed data collection records takes place 
at a later moment as batch processing which is separate from the generation 
5 of call detailed data collection records. It should be noted that in practice 
billing may be even much more complicated than the example described 
above. E.g. in a mobile station network, each mobile services switching 
centre taking part in the call may generate call detailed data collection rec- 
ords. However, the billing principle is as described in the foregoing. 
10 Processing of a CDR format in present fixed network telephone 

systems is described in the following refernng to Figure 2. The figure shows 
functions of the telephone exchange which are essential from the viewpoint 
of the invention. 

The call detailed data collection process obtains information related 
15 to the call as raw data in individual messages mainly from the call control. 
The call detailed data collection process saves the information in a record 
reserved for the call. On termination of the call or in connection with interim 
data collection, the data collection process sends the call record as a whole 
in messages of various types to the process for saving of call detailed rec- 
20 ords. The message has a call type number indicating the nature of its con- 
tents and a message sequence number. The structure of successive mes- 
sages is always the same and the type will determine which fields in the 
message must be filled in. If the number of fields to be filled in is less than 
the number of fields in the message, then void fields are filled in with a filling 
25 code. The messages are thus always sent in their entirety. 

The saving process goes to read the message structure in a sepa- 
rate format file and starts formatting of the record from a raw data flow which 
it receives. The structure of the call record and of the format file is fixedly 
structured in the code of the process for storing the call detailed data collec- 
30 tion. Fixed coding is done, because the place of the field in the call record is 
not found out from the format file. The process for saving the call detailed 
data collection reads the formatting file successively and from the received 
call record it picks up a field for locating it in the CDR, if in the formatting file 
the said field is defined as one to be taken along. The manner in which the 
35 individual field is coded in the CDR is also fixedly established in the code of 
the process for saving the call detailed data collection. 
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If it is desired in some application to have a different processing for 
some field in a message, e.g. a time field format, then this must be done 
through control of the application switch. 

When the process for saving the call detailed data collection has 
5 completed the CDR, it locates it in the RAM block. Normally, one block can 
accommodate 5-10 CDRs. When the block is completed, it is saved on the 
hard disk of the concerned telephone exchange or it is sent outside the ex- 
change to some I/O equipment, e.g. to the hard disk of the operation control 
centre. It is also possible to send received blocks directly to the post proc- 
10 essing process. 

It is possible for the operator to output e.g. CDRs formatted of 
some subscriber's calls from a block saved on the hard disk of the operation 
control centre. This is done with a Man Machine Language (MML) command. 
The command starts a read program, wherein the structure of the format file 
15 of call detailed data collection and the names of fields corresponding to its 
sub-files are fixedly coded. Reading is performed from the ring buffer of the 
hard disk. 

Formats saved in the formatting file will also be briefly described. 
The operator brings about the format he desires with an MML command. The 

20 command will first output for the operator in plain language in the monitor 
display all fields .1. sub-files available in the message. Thereupon the opera- 
tor selects those fields which he wishes to locate in the format to be made. 
From the available fields the operator may take a field or remove a field, but 
he can not change the order of fields. When the user has made his choice, 

25 the format is completed and it may be output to the display or printed out on 
paper. The output will indicate in plain language which fields are present in 
the format. 

The format may be e.g. in the form 
CALL SUBSCRIBER NUMBER 10 

30 whereby the name of the field is call subscriber number and the 

numerical value 10 expresses the place of the field combination in the CDR. 

The MML function reads the fields (sub-files) available in the format 
file of the call detailed data collection process and uses the same both in the 
MML command, with which the user creates the format he desires, and in the 

35 MML command, with which the format chosen by the user is output onto the 
display or on paper. It is shown by the format file which fields can be chosen 
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and whether the chosen field is present in the call detailed record CDR. The 
format file contains as many sub-files as the maximum number of fields in 
the call detailed record CDR. 

The structure of the format file's sub-fiie is of the type: 
FIELD_IN_RECORD POSITION 
TRUE 0 
5 As can be seen from the shown type, it does not indicate the field 

name in plain language. For this reason, the names of fields in plain lan- 
guage as well as their correspondence in the format file are fixedly coded in 
the MML function. Coding is e.g. as follows: 

IF CRPARA.SUB_REC(1),FIELD_lN_RECORD=TRUE THENDO: 
10 CALL MOVBC'CALL TiME",MML_FORMAT.RECORD_HEADER.. . 

This means that if a field located in position 0 from a format file.by 
the name of CRPARA, which field is here called FIELDJN_RECORD,. is 
true, that is, the user chose it when making the format, then it is given. -the 
name CALL TIME in plain language. - 
15 There are some drawbacks in the state-of-the-art formatting of call 

detailed records described in the foregoing. 

Firstly, when call detailed records are sent from a telephone ex- 
change to a billing centre performing post processing, the data flow to be 
sent is a big one. Above all, it contains plenty of void or unmarked fields. 
20 When the raw data flow contains data in binary form, in hexadecimal form 
and in ASCII form, then the formatted CDRs will also contain data which is in 
different forms. Data in different forms will add to the quantity of data to be 
transmitted from the exchange. 

Secondly, if the billing centre wants CDRs of other kinds, that is, to 
25 add new fields or to remove fields presently in use, it is not only difficult but 
also risky to make any changes, since it must unconditionally be ensured 
that any changes made in the formatting file are made correctly and that the 
receiving end of the post processing site, that is, the billing centre, is able 
correctly to interpret the changed CDR data flow. In addition, some data is 
30 also usually lost when the format is changed. 

Thirdly, since in the state-of-the-art arrangement the incoming data 
flow in all functions related to the format or field names and their correspon- 
dence in the format file are fixedly coded in the program blocks, necessary 
changes must always be made in the call detailed data collection saving 
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process, in the data collection process, in the MML program and in programs 
related to output of CDRs when an entirely new data element is desired in 
the format. Besides changes in programs, the formatting file structure must 
also be changed and a change must be made in the conversion program of 
5 this file. The second and third items are so troublesome that the exchange 
supplier must know which format the buyer desires even a year before the 
exchange is delivered to the buyer. Thus, it is both difficult and expensive to 
change the format once it is made. 

The present invention aims at a method not suffering from the 

10 mentioned drawbacks in use. The objective is thus a method where chang- 
ing of the format is more dynamic and more reliable than in any known 
method. It ought to be possible to change the format "on the move" and post 
processing must be prepared at once to process any changed CDRs. It 
should be possible to create different CDRs for various purposes and thus 

1 5 also to bring about CDRs which are shorter than present CDRs. 

The established objectives are achieved with the method and sys- 
tem described in the independent claims. 

Brief summary of the invention 

20 The invention is based on the idea to use a special form for ex- 

tracting desired data from a raw data flow. The number of forms may be 
high, however, so that there may be only one active form for each type of 
message. Each form defines exactly that information, which should be ex- 
tracted from the raw data flow in order to format a CDR. When a form is acti- 

25 vated, the formatting process will extract the data determined by the form 
from the data flow. 

To this end, the exchange supplier formats a special mother form 
showing in plain language (in ASCII form) all the names and parameters of 
fields arriving as a raw data flow. Thus, the mother form is a file containing 

30 the message structure. Each different message has its own mother form. 
The mother forms are delivered to the user e.g. on a diskette. The user has a 
program using a graphic user interface which shows the desired mother form 
in the display. Beside this a user form blank can be seen and the user 
chooses the fields he desires simply by using the mouse to drag the field of 

35 his choice from the mother form to the user form where he drops the field he 
has chosen (drag and drop). In this manner the user makes his own form. 
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which contains only the data he wants to include in the CDR. If the user so 
desires, he may also determine the form in which he likes the data to be. It is 
possible that the user wishes all data to be in binary form. The user delivers 
his form e.g. on a diskette to the exchange and to the billing centre. 
5 On arrival of the user form at the telephone exchange, it can be ac- 

tivated at any time. When the form is active, the formatting process will use 
this form in the manner of a filter and extracts from the raw data flow the data 
corresponding to the fields indicated on the form, thus formatting the CDR. 
When the CDR is completed, the exchange will send it to the billing centre, 

10 which using the same form made by the user will interpret the data contained 
in the received CDR, that is, it creates fields and attaches the data belonging 
to the fields from the CDR. The names of fields are thus not transferred from 
the exchange to the billing centre. 

Before activation of the user form, it is possible to test the form. 

15 Hereby in the exchange the formatting process makes the CDRs defined in 
the form and sends them to the billing centre. This for its part will find that--the 
CDRs are test CDRs and will handle them accordingly. Only after testing has 
shown that the user form works correctly both in the exchange and in the 
billing centre, it may be put into active use. 

20 

Brief description of the drawings 

The invention will be described more closely in the following with 
the aid of the attached diagrammatic drawings, in which 

25 Figure 1 shows the billing principle, 
Figure 2 shows formatting of CDRs, 

Figure 3 shows network elements taking part in implementation of the inven- 
tion 

Figure 4 shows a mother form, 
30 Figure 5 shows a user form. 

Figure 6 illustrates formatting of a user form, and 
Figure 7 shows use of the form in formatting of CDRs. 

Detailed description of the inv ntion 

35 Figure 3 shows a telecommunication network which may be a 

PSTN or an ISDN network and which comprises several telephone ex- 
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changes 1,2,..,N, each one of which formats a subscriber record CDR relat- 
ing to a call made by a subscriber through an exchange. The Network Man- 
agement System NMS indicated by reference number 4 attends to network 
management by controlling various exchanges. The billing centre BC indi- 
5 cated by reference number 5 receives call detailed records CDR arriving 
from different exchanges, it processes them and forms bills to be sent to 
subscribers. If there is no separate network management, then control and 
configuration of the exchange may be performed in the exchange proper in- 
stead of using remote operation. Reference number 6 indicates a general 

10 purpose computer, which contains a program with which the operator/user 
uses a mother form for making a user form according to the invention. The 
supplier of the telephone exchange for his part makes the mother form in a 
manner explained hereinafter. 

The exchange supplier naturally has exact information about the 

15 contents of the raw data flow arriving in the message. The message struc- 
ture is always the same, that is, the fields of the message and their parame- 
ters (location, length, type etc.) are constant. The message type determines 
which fields wilt be filled in when forming the message. The message is al- 
ways sent in its entirety, so any fields left void must be filled with filling code. 

20 Thus, the type of message may change, although the message number re- 
mains the same. The message number and the type of data block arrive in 
the data flow. Table 1 below illustrates the contents of a message. 



signal charging_msg_s = 
( 



scq number 

order_numbcr 

call_record_ind 

in_cgr_name 

out_cgr_name 

call_rccord 

service record 



byte; 
dword; 

rccord_numbcr__t: 
cgr_nanne_t: 
cgr_name_t; 
call_rccord_t; 
svct'il t: 



25 



Table 1 



The message is a "signal charging message" and its number is 
0x4543. The data flow of the message is successive fields of different 
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lengths, e.g. the first field in position 0 is seq_number and its length is one 
byte, the next field in position 2 is orde renumber and its length is n word. In 
reality, there are no field names in the message, but the message consists of 
field bits, which are after one another without break and without any separa- 
5 tor marks. However, the location of each field is determined unambiguously 
when field positions and lengths are known. Thus, e.g. the beginning of the 
third field's call_record_ind (position 3) is found out, by jumping from the be- 
ginning of the message by the number of bits of the two preceding fields of 
messages, that is, forward by one word and one byte. From this point for- 

10 ward there are as many bits of the third field in the flow as is indicated by 
the length of the field. 

Since the exchange supplier always has a tool, that is, a program, 
with which the message structure can be opened as position and field data, 
it is simple to use this program and a suitable windows© program for making 

15 the mother form. The Windows program is used for making a form having a 
form header and CDR headers of the desired form. The headers are in plain 
language. Placed under the headers are field names and field data such as 
the toolkit has opened them from the message. All fields are contained in' the 
mother form. However, the order of fields need not be the same as in the 

20 message data flow. The toolkit functions as a link between message fields 
and the contents of fields in the data flow. 

Figure 4 shows the form of a mother form. The file name seen in 
the top part of the form contains mother form data; the first digits of the se- 
ries of numbers, here 4543, give the message number to which the form is 

25 related, the next three digits 000 indicate the type of message. The letter M 
indicates that the form is a mother form. The three digits after full stop indi- 
cate the version in succession of the mother form: if the message is 
changed, the mother form will of course also be changed, whereby it will 
have a new version number. This data contained in the file name is not part 

30 of the form proper, but it is brought into the display by the windows© pro- 
gram. 

The form header on the following line contains the fields Format 
Number, which indicates the message number and type. Output Mode, 
which here is BIN and indicates the mode of the CDR produced with the 
35 form, and Output device, which indicates where the CDRs to be formatted 
are saved. The place of storage may be e.g. VDS, that is, Virtual Disk Sys- 
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tern or VIDAST, where some hundred CDRs are collected on the disk and 
are then sent as a cluster to the billing centre. Output device may also de- 
termine that the CDR be sent immediately after formatting to the Hot Billing 
System. 

5 Then comes data relating to the header line of the CDR to be for- 

matted on the mother form. The data relates to CDR headers and is grouped 
under the Header field name, Type and Length of the headers. Thus all 
header fields and their data existing in the message and uncovered with the 
toolkit will come under Header field name. In the examples, the record 
10 length, hea_record_length, is first as record type W (Word) and length 2 
words. 

After these comes data relating to data fields of CDRs of the mes- 
sage proper. This is grouped under headers Data field Name, Type, Length, 
Position and Format. All data fields and their data existing in the message 
15 and uncovered with the toolkit come under the headers. The form shows e.g. 
subscriber A's field, the data type, length, position (26*^ byte in the message) 
and format (BCD coded). In the Format column of the form the character of 
the field is indicated: BCD means Binary Coded Decimal, DM is datum. The 
numbers located after these are instructions for the formatting program. E.g. 
20 number 1 might mean convert the binary coded data into BCD format. 

The mother form according to Figure 4 is thus formed for each 
message. The header and data fields and their parameters can be seen in 
each form in a form which is easy to read and in plain language. The work 
station is able to make the linkage from a field on the mother form to the right 
25 spot in the raw data flow. 

After the mother form has been formatted by the supplier of the 
telephone exchange, e.g. in the telephone exchange shown in Figure 3, a 
copy of it will be transferred from the computer to a diskette. The mother 
form on the diskette is of a read-only type, so it can not be edited in any way. 
30 This means that when the exchange supplier has made the mother form and 
delivered it to the operator, the latter can not change the mother form. Of 
course, the supplier may make changes. 

Thereafter the diskette is taken to the operator's billing centre or to 
the network management unit, and it is pushed into a general purpose com- 
35 puter, e.g. into computer 6 in Figure 3. This computer has a windows based 
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program, which creates a user form and the operation of which will be de- 
scribed in the following. 

The user form shown in Figure 5 has a lay-out which is quite similar 
to that of the mother form. Thus the file name of its top part contains the 
5 same data as in the mother form: the first digits 4543 of the series of num- 
bers give the message number, to which the mother form and thus also the 
user form are related, the following three digits 003 indicate the message 
type. The letter P states that the form is a passive form. The significance of 
this will be explained later. The full stop is followed by three digits stating the 

10 version of the user form: the user may at any time create a new form, 
whereby it will have a new version number. 

The form header on the following line contains the fields Format 
Number, Output Mode and Output device, which states that the CDR to. be 
formatted with the form will be saved on a diskette. 

15 These are followed by data relating to the first header line of the 

CDR to be formatted, Header field name, Type and Length. The proper fields 
contained in the CDR come under Data field Name. Type, Length , Position 
and Format. 

The said form headers and header lines come automatically ac- 
20 cording to the mother form into the user's computer display when he has 
started the program and has pushed the diskette into the read station. The 
field names are exactly the same as in the mother form and they can neither 
be changed nor must they be changed. 

Figure 6 shows a view seen by the user after starting the program 
25 and after he has pushed the diskette into the work station. The view is a typi- 
cal windows view with its basic keys. On the right hand the diskette has pro- 
vided a mother form according to Figure 4, which contains alt possible mes- 
sage fields. On the left hand is a user form blank according to Figure 5. The 
user picks up the fields he desires from the mother form simply by choosing 
30 them with the mouse and by dragging them into the user form and dropping 
them under the respective field header. Thus, in the case shown in the fig- 
ure, the user has chosen from the header fields of the mother form the first 
four fields, but from the data fields only Subscriber A's field and those fields 
which give the start time of the call and the end time of the call respectively. 
35 It is possible for the user in some cases also to change parameters 

of the fields. Thus e.g. the length of the Subscriber A field, which is 16 char- 
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acters in the figure, may be shortened to 8 characters by replacing the num- 
ber 16 with the number 8. 

When the user has made the form he desires, it is saved and 
transferred in one way or the other to computer 5 in the billing centre and to 
exchange 1 , Figure 3. Field "customer form" in the top part of the form con- 
tains status code P, which means a passive form. 

Saving may be done on a diskette, which is taken to the OMU unit 
(Operation & Maintenance Unit) of the telephone exchange and to the billing 
centre. 

Saving may also be done in such a way that the user form is 
transferred as a file transfer or the diskette is taken to network management 
4, Figure 3. When he desires, the user of this will press e.g. the send key on 
the computer 6, whereby, network management will transfer the user form to 
the telephone exchange and to the billing centre. 

Testing of the user form can now be performed. When the form has 
been transferred to the telephone exchange and to the billing centre, testing 
is performed without interfering with any formatting and sending of CDRs 
which are going on at the time. Testing is carried out in such a way that net- 
work management gives the name of the passive form to be tested and the 
exchange is notified that this form is being tested. The MML function then 
feeds such a test data flow to the telephone exchange which has the struc- 
ture of a proper message. The test data may be a binary file corresponding 
to binary data of the correct message and which may be edited. From the 
incoming test data flow the formatting process picks up the data corre- 
sponding to fields specified in the form and formats CDRs according to the 
form. The formatted test CDRs are sent among CDRs proper to the billing 
centre. 

The test CDRs are data queues of a certain length which are sent 
to the billing centre as they are produced. Since it has at its disposal exactly 
the same user form as the one with which desired data was extracted from 
the test data flow during the formatting process in the exchange, it is able by 
using the same form as interpreter easily to format field names and to ap- 
pend to these exactly correct data from the data flow. As a result, the billing 
centre obtains in the display the field names given in the form and the correct 
records under the names. 
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For the billing centre to be able to distinguish test CDRs from 
proper CDRs, the arrangement may be such that the test form produces 
some separator in the CDR, whereby the billing centre will not take the test 
CDR to post processing proper. It is of course possible to take test CDRs to 
5 post processing proper and to format telephone bills of them. This is advan- 
tageous so that the correct function of the test form can be ensured until the 
end. The separator marks in the test CDRs guarantee that formatted tele- 
phone bills will not be sent any further. 

When testing has shown that all is working without fault, the form 

10 which is in a passive state (mark P) may be activated by changing the mark 
into A (Active). Activation is done e.g. by network management by using the 
windows program to bring up the passive form and by pressing the "activate 
form" key, Figure 6. The change from passive into active is done in the tele- 
phone exchange. Thereupon the call detailed data collection saving process, 

15 Figure 2, immediately puts the now active user form into use and begins for- 
matting CDRs, wherein there are records indicated in fields of the form., The 
formatted CDRs are sent by the telephone exchange to the billing centre, 
which using the same form can extract the correct records from the data 
flow. 

20 Some checks may be made in the telephone exchange as regards 

the formatted CDRs. Firstly, an initial check can be made by ensuring- that 
the call end time minus the call start time picked up from records is equal to 
the length of the call. Secondly, a CRC check or some other known transfer 
protection may be added to the data to be sent on the transfer path from the 
25 telephone exchange to the billing centre. Thirdly, a separator mark of suffi- 
cient length may be added to forms so that formatted CDRs can be clearly 
distinguished from each other 

Figure 7 shows the use of user forms in a telephone exchange. The 
user forms in a passive state are saved in the OMU. In function 71 the user 
30 makes the form or forms he desires, which are then taken on a diskette to 
the telephone exchange or to the network management common to all ex- 
changes and to the billing centre. The user requests that an MML command 
be given for performance of the test. 

When the operator wishes to introduce a certain form to get the 
35 CDRs he desires, he presses the Activate Form key in the program, which 
gives the MML function a request for activation of the form. The command 
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picks up the desired form from the directory and makes it active, function 72. 
At the same time, the billing centre has introduced the same form. The for- 
matting process 73 produces desired CDRs, which are sent to the billing 
centre. 

The use of forms according to the invention allows very flexible ed- 
iting of CDRs. When e.g. it is desired to add a field to the CDR, say, an en- 
cryption code, an old form is taken as a basis and the encryption code is 
added to it. The Windows program generates a new version of the form, 
which will have a new format number. The new form is sent to the telephone 
exchange and to post processing. During this time, the CDRs are still filled 
with the old form. After the test CDR has been sent and the functioning of 
post processing has been ensured in the billing centre, the new form is acti- 
vated at the same time as the old form is made passive. The exchange will 
immediately produce CDRs, wherein the encryption code is present and 
which carry the new format number. The format is thus exchanged on the 
move. 

The use of forms is also very convenient when raising the ex- 
change standard, which means changing of the exchange software. Hereby 
generated and frozen mother forms corresponding to the new standard and 
having as their file name e.g. 4543000M.100 are taken to a new directory of 
the computer. The version number has been changed here into a new hun- 
dred number and the first number is 100. The now active user forms are then 
copied into the same directory and a conversion program is run, which will 
convert old user forms to correspond with the new message, where fields 
have new positions. Field names are used as search keys. The version is 
changed in the conversion, e.g. 4534003A.008 4543003P.101 and like- 
wise the format number changes e.g. 003008 -> 003101. New passive forms 
are then sent to the telephone exchange on the so-called trial side, where 
testing of the new software is performed without interfering with the old run- 
ning software, and to post processing. Next, new test CDRs are sent from 
the trial side, if possible, and the functioning of post processing is ensured. 
Upon completion of testing, the new forms are activated from the trial side 
and switch-over is done, whereupon the new forms are in use. 

If there is no separate network management and billing centre in 
the network, the user form is made with the aid of a separate general pur- 
pose computer, which is indicated by reference number 7 in Figure 3. 
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The mechanism of the invention has the advantages that change of 
format can be done dynamically on the move and post processing Is imme- 
diately synchronised into the change. Several different CDRs can be made 
for different requirements, whereby it is possible to format short CDRs. A cor- 
5 rect functioning is ensured by sending test CDRs. The form contains all the 
data relating to formatting, transferring and interpretation of CDRs. CDR for- 
mats are managed in a centralised manner and the same graphic user In- 
terface is used both by the exchange supplier and by the operator. 
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Claims 

1. A method of formatting billing records in a telephone exchange, 

wherein 

call records come in messages of different types containing raw 
5 data to the formatting process, which formats call detailed records (CDR) to 
be sent to a billing centre, 

there is a toolkit for opening the message structure containing raw 
data into field headers and field parameter data, 
characterized in that 
10 of the opened message a mother form is formatted, which is a file 

and which contains all field headers and field parameter data of the message 
in plain language, 

a user form is formatted, which is a file, by choosing in a desired 
order desired field headers and their parameter data from the mother form. 
15 call detailed records (CDR) are formatted by separating data of 

fields specified in the user form from the incoming message. 

2. Method as defined in claim 1, characterized in that for 
each message a separate mother form is formatted. 

3. Method as defined in claim 1, characterized in that the 
20 message number and the message type identifier and the mother form's ver- 
sion number are placed in the file name of the mother form. 

4. Method as defined in claim 3, characterized in that the 
file name of the user form is given in accordance with the file name of the 
mother form, so that the message number and message type identifier are 

25 transferred to it and the user form's version number is located in it. 

5. Method as defined in claim 3, characterized in that such 
a status data field is placed in a header field of the user form which states 
whether the user form is passive (P) or active (A), and in that call detailed 
records (CDR) are formatted according to fields specified in this user form 

30 only when the form is active. 

6. Method as defined in claim 1, characterized in that the 
mother form is formatted by the supplier of the telephone exchange while the 
operator formats the user form. 

7. Method as defined, in claim 1, characterized in that the 
35 supplier of the telephone exchange formats both the mother form and the 

user form. 
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8. Method as defined in claim 5, characterized in that 

the user form is tested before its activation, so that test call detailed 
records are formatted with its aid from a test data flow, 

a separator mark is placed in the formatted test call detailed rec- 
5 ords before they are sent to the billing centre 

the billing centre extracts the test call detailed records from the in- 
coming data flow using the user form. 

9. Method as defined in claim 5, characterized in that in 
response to activation of the passive user form, the formatting process of the 

10 telephone exchange immediately begins formatting call detailed records 
(CDR) by extracting data of fields specified in the user form from incoming 
messages. 

10. Method as defined in claim 1, characterized in that the 
billing centre uses the user form for interpreting data of received call detailed 

15 records. 

1 1 . Method as defined in claim 10, characterized in that in 
response to activation of the passive user form, the billing centre immediately 
begins using the user form for processing received call detailed records: 

12. Telecommunication system comprising 

20 several telephone exchanges, wherein call records in various types 

of messages containing raw data arrive in a formatting process which for- 
mats call detailed records (CDR), and which sends the call detailed records 
further, 

a billing centre which receives call detailed records (CDR) and 
25 performs post processing of these to format telephone bills, 

possibly network management for controlling the operation of tele- 
phone exchanges. 

characterized in that the system comprises; 

at least one mother form, which is a file and contains all field head- 
30 ers and field parameter data of the message, 

at least one user form, which is a file and where desired field head- 
ers and their parameter data are located in a desired order from the mother 
form, 

means of activating the user form in the telephone exchange so 
35 that the formatting process will format call detailed records (CDR) by sepa- 
rating data of fields specified in the user form from the incoming message. 
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13. Telecommunication system as defined in claim 12, 
characterized in that the user form is also placed in the billing centre 
and that when the user form is active the billing centre uses this user form for 
extracting data of fields specified therein from call detailed records (CDR). 
5 14. Telecommunication as defined in claim 12, 

characterized In that in response to the operator's request for acti- 
vation the netv\/ork management performs activation of the user form of the 
telephone exchange. 

. 15. Telecommunication system as defined in claim 12, 

10 characterized in that the mother form is made by the supplier of the 
telephone exchange as a file delivered to the operator as a diskette record- 
ing and that the user form is made by the operator based on the mother form 
as a file delivered to the supplier of the telephone exchange and to the billing 
centre as a diskette recording or through the network. 

15 16. Telecommunication system as defined in claim 11, 

characterized in that both the mother form and the user form are 
ASCII files. 



B^fSDOCID: <WO 9S49e25A1J_> 




BNSDOCID: <WO 9849825A1J_> 



wo 98/49825 PCT/F198/00289 



2/7 

CALL CONTROL 

CALL DETAILED 
DATA COLLECTION 
PROCESS 



rA E 



RAW DATA BLOCKS 



MESSAGE: NRO 
TYPE; NRO 



MESSAGE: NRO 
TYPE: NRO 



5 



PROCES OF SAVING 

CALL DETAILED 
DATA COLLECTION 



CDR 



CDR 



CDR 



Fia. 2 



BNSDOCIO: <WO 9849825A1J_> 




BNSDOCID; <WO 9849825A1_L: 



wo 98/49825 PCT/FI98/00289 



4/7 



Mother -Form: 4543000M.000 



Format Number Output mode Output device 



003000 


BIN 


DISK 


Header field name 


Type 


Length 


hea_record_length 


W 


2 


hea_tbrmat_number 


W 


2 


hea_exchange_id 


B 


10 


hea savina time 


B 


8 



Data field Name 


Type 


Length 


Position 


Format 


storage_code 


W 


2 


0 




establishment_code 


DW 


4 


2 




calMdentifier 


DW 


4 


6 




a_subscriber 


B 


16 


26 


BCD 1 


b_subscriber 


B 


16 


43 


BCD 1 


start_time_of_call 


B 


8 


145 


DM 2 


e n d_t ime_of_c al 1 


B 


8 


153 


DM 2 


clear code 


DW 


4 


166 





Fig. 4 



BNSDOCID: <WO 9849825A1J_> 



wo 98/49825 



PCT/FI98/00289 



5/7 



Customer-Form: 4543003P.0()1 




Format Number Output mode 


Output device 


003001 BIN 


DISK 


Header field name 


Type 


Length 


hea_record_length 


W 


2 


hea_format_number 


W 


2 


hea_exchange_id 


B 


10 


hea_saving_time 


B 


8 


Data field Name Type Leng 


lit Position Format 


a^subscriber B 


16 


26 BCD 1 


start_time_of_call B 


8 


145 DM 2 


end__time_of_call B 


8 


153 DM2 









Fig. 5 



wo 98/49825 




O 






o 
-a 
c 



C 
O 

r- 



> 



-a 



O 
O 
O 



CO 

o 
o 

CO 
ID 

E 

o 



0) 

o 



0) 

o 
■> 

0) 
■D 

O 

0) 

is 

^ CD 
=3 
Q. 

o 

O) 

3 O 

|i 



o 
o 

• 

a. 

CO 

o 
o 

CO 



o 

I 

o 

E 
o 

o 



O 

C 

= CO 



4 CO 

c o 

u o 
c 



6/7 



PCT/FI98/00289 



^ O « 

C (N CNJ CO 

0) 



0) 
Q. 



CQCQ 



m 
E 
o 

Ll. 

c 

O O CN CD 

o 

CL 

£ CN T;r 

c: 



Q 

O 
00 



Q 

O 
CD 



„ CD 

<X> Zi- ^ ^ ^ 
^ ^ 1^ ^ 



^ ^ CO CX3"^ 



^ -a 

D5 P (U 



a 



Q Q CQ^^ CQ CD Q 



i g'i 

03 0 ^ 



C7) ■ 



2 "2 2 

.2 8 ^ o i 

t 2^ o S S 

0) I I I I 

"O CI3 ro 03 03 

(0 <U (D Q) Q) 

OJ -C ^ JZ 

X 



0 

E 

cu 
re 
Q 



CD 

"a 

o 
u 

I 



"3 -= 



03 
U 



I- 



■a 



CD f/) 

-2 03 
(/) CU O 



CD ^ 



(D CD O 

(D 

O O F r- 
C/) t/) C 

3 3--' i 1- 

{/) c« ^ -a oj 
i !-5 c 0) 

CO -Q CA) (D O 



O 
O 



c 

CD 



CNJ CNJ 



CO 



^ CNJ CN 

§ 8 ^ ^ 

O CO Q Q 

c 
o 

'yj ^ LO CO 



CQ in 



o 
a. 

-4--) 

C 

<D 



CNJ LO 



C^ CO CO 



5; CQ CQ CQ 



0) r- (D 

E ^ -g :g 

CO 

c 



2 -r," ^! 
0) ^ ^ 



o 
o 

tp 03 

q; CD 



01 



03 
(D 



CD 
E 



Ol 

03 

O > 
X 00 
(D W| 

03 

(D 0^ 



a> 

E 
ca 



03 



o 



03 
O 



CD 



:2 o ^ 



CD 



(U en E p 
.E 



03 

TO 
O 



"^1 ^ 



CD 



BNSOOCID: <WO__9S49825Al_L> 



wo 98/49825 PCT/FI98/00289 



7/7 




BNSOOCID; <WO. 



> 9849825A1 J_: 



INTERNATIONAL SEARCH REPORT 



Iriicriiaiionnl application Ntj. 

PCT/FI 98/00289 



A. C:i,ASSH"!CA riON Of SUIULCI MA Ti TR 



IPC6: H04M 15/00 

AcL-ordint^ lo Inlernaliunal Palcnl Classific^.linn (IPC) or lo btiih naiiun.i! chissifi(;;uiun and IPC 



n. Min.[)S SliARCHt-D 



Minimum clocuincnlalion searched (ciassifiL-aiion syslcm fnlluwcd by classificatiun symbols) 

IPC6: H04M, G06F, H04Q 



Documcniaiinn searched nlher than minimum dticumcnlaliun Lo the extent thai such documents are included in the fields searched 

SE,DK,FI,NO classes as above 



r.locironic data base consulted during the iiilcmationa! search (name of data base and, where practicable, search terms used) 



C:. IX)(:UMl:N'rS CONSIDP.RRD to BH RF^U-A'AN r 



Lllntioii of document, wtih indication, where approjniale. of'llie relevant passniics 



Relevant lo claim No. 



WO 9308661 Al (TELEFONAKTIEBOLAGET LM ERICSSON), 

29 April 1993 (29.04.93), page 4, line 20 - page 6, 
line 31, see the claims 



US 4979207 A (DAVID M. BAUM ET AL) . 

18 December 1990 (18.12.90), see whole document 



WO 9524094 Al (BRITISH TELECOMMUNICATIONS PUBLIC 

LIMITED COMPANY), 8 Sept 1995 (08.09,95), page 2, 
line 26 - page 5, line 16 



1-16 



1-16 



1-16 



□ 



hurilier documents are listed in the continuation of* Rox C. 



)( See patent family annex. 



* Special calcgr>riL's of cited documcnls: 

"A" d<iciiincni dtiiniiig ihc Rcncral .dale of ihc an '.vhich is not considered 
u» he of particular relevance 

eriicr document hut puhli<;hed on or after the inlcmationfil filing date 

"L" docunicni which may doubts on prionly claim^s) or which is 

cUcd to eslahli^h ihc publication dale o( another citation or other 
'i-];cciai reason (as .spec; Tied) 

"O" document referring to an oral disclosure, use, exhibition or other 
means 

"V " documcnl published prior to the international filing dale but laicr ihan 
Ihc priority date claimed 



"T" later document puhlt.shcd after the international filing date or priority 
dale and not m conflict with the application hut cited to understand 
the principle or theory underlying the invention 

"X" document of particular relevance: the claimed invention cannot he 
considered novel or cannot be considered to involve an inventive 
step when the docutncnl is taken alone 

"\" dftcument ol particular relevance: the claimed invention cannot be 
considered lo involve an inventive step when the documcnl i.s 
combined with one nr more other such documents, such combination 
being obvious to a person skilled in the art 

document member nf the same patent family 



Dale of the aclual ctJinpletion of the international search 



14 Sept 1998 



Date oi' rnniling t>f ihe inlerttaiional search repcirt 

1 6 -09- 1998 



Name and mailing address of tlie ISA.-' 
Swedish Patent Office 
Box 5055. S-102 42 STOCKHOLM 
[•"acsimilc No. r 46 8 (,(^Cj 02 8f) 



Aiilhorized ollicer 

Cecilia Sandell 

Telephone No. +46 8 7S2 25 00 



1-orm I'Cf 'ISA-210 (second sheet) (July 1992) 



BNSDOCID: <WO 9849825A1 _!_> 



INTERNATIONAL ^SBAJICH REPORT 

Iiif'ontiatioii on pnlcrii liKiiily mcntbers 



Inlcinntiodnl application No. 

PCT/FI 98/00289 



P:ilt;tit document 


Puhlic.iiion 




Patent family 




Publication 


cilcd in search reporl 






mcmbcr(s) 




date 


WO 9308661 Al 


29/04/93 


AU 


658102 


B 


30/03/95 






AU 


2779392 


A 


21/05/93 






GB 


2274045 


A,B 


06/07/94 






GB 


9404130 


D 


00/00/00 






JP 


7500464 


T 


12/01/95 






SE 


9401229 


A 


09/05/94 






US 


5218632 


A 


08/06/93 


lis 4979207 A 


18/12/90 


CA 


2034600 


A,C 


02/08/91 






GB 


2246051 


A 


15/01/92 






IL 


97016 


A 


27/02/94 






MX 


171385 


B 


21/10/93 






US 


5027388 


A 


25/06/91 


WO 9524094 Al 


08/09/9b 


A t t 

AU 




b 


(lo/ lu/ y / 






AU 


1820095 


A 


18/09/95 






CA 


2184190 


A 


08/09/95 






CN 


1145150 


A 


12/03/97 






EP 


0748558 


A 


18/12/96 






JP 


9509805 


T 


30/09/97 






SG 


43099 


A 


17/10/97 



I-urm PCr iSA.'2lt) (patent family aiinux) (July \HH1) 



BNSDOCID: <WO 9849825A1J_> 



Page Blank (uspto) 



